1. Field of the Invention
The present invention relates to secure claim and defense of a network addresses for a node in a computer network. In particular, the present invention relates to secure claim and defense of a network address by a network node other than the one from which the network address originates.
2. Discussion of the Related Art
U.S. Patent Application Publication 2002/0133607, entitled “Address Mechanisms in Internet Protocol” (the “Nikander Application”) discloses using a one-way coding function to generate an Internet Protocol (IP) address from one or more components specific to a host which claims the IP address. In the Nikander Application, a recipient of a message from the host reconstructs and checks the IP address using the components. The claiming host uses an authentication protocol or a public key cryptographic protocol to establish data integrity on the message, the tie between the components and the address.
U.S. Patent Application Publication 2002/0152384, entitled “Methods and Systems for Unilateral Authentication of Messages” (the “Schelest Application”) discloses deriving an IP Version 6 (IPv6) address hashing the claiming host's public key. In the Schelest Application, a recipient of a message from the claiming host checks the hash of the IPv6 address, and checks a cryptographic signature in the message to verify its data integrity. If both the IPv6 address and the enclosed signature are verified, the recipient accepts the host's claim of ownership over the IPv6 address.
“Crypto-Based Identifiers (CBIDs): Concepts and Applications” (the “Montenegro Paper”) by Gabriel Montenegro and Claude Castellucia, ACM Transactions on Information and System Security, Feburary, 2004, reviews the area of cryptographically generated identifiers and their use in establishing authorization to claim the right to use an address by a single host.
U.S. Patent Application Publication 2003/00849293, entitled “Addressing Mechanisms in Mobile IP” (the “Arkko Application”) discloses an owner node delegating the responsibility for its IP address to a second node when the address is generated. In the Arkko Application, the IP address may be cryptographically generated using the methods disclosed in the Nikander or the Schelest Applications. Under the method of the Arkko Application, the owner node obtains a public key of a public/private key pair from the second node, and creates an authorization certificate by signing the obtained public key using the owner node's own private key. The authorization certificate is then provided to the second node, which may then distribute it in any message relating to the owner node's IP address. The second node signs this message, including the authorization certificate, with its private key. A recipient node uses the second node's public key to verify the message and the owner node's public key to verify the authorization certificate. The cryptographic hash of the address verifies the owner node's right to the address and the verified second node's public key in the authorization certificate establishes the second node's right to send messages on behalf of the owner node.
IETF Request for Comment (RFC) 3972, by Tuomas Aura, March 2005, discloses generating, cryptographically, an IPv6 address and securing the claim of authorization for the IPv6 address in the Neighbor Discovery Protocol (RFC 2461 and RFC 2462). The IPv6 address is generated using both the cryptographic hash of the public key of the owner node and additional information. 64 bits of cryptographic hash serves as the interface identifier of the IPv6 address.
U.S. Patent Application Publication 2002/0152380, entitled “Methods and Systems for Unilateral Authentication of Messages” (the “O'Shea Application”) discloses using a public key for a single host, as described in the Schelest Application, to cryptographically generate a Mobile IPv6 home address and care-of address. The Mobile IPv6 home agent in the home network forwards to the care-of address data packets addressed to the home address, when the mobile node is located outside the home subnet. The mobile node may request that a correspondent node address packets directly to the care-of address, rather than through the home address, thus improving routing performance—a process called “binding update for route optimization.” The signaling to optimize routing in this manner requires some proof that the mobile node is authorized to claim the new care-of address. The proof may be provided using the cryptographic properties of the network address and a public key signature on the signaling packets. The mobile node signs the binding update signaling packet with the private key corresponding to the public key used to generate the network address. The signaling packet is sent with the source address set to the new, cryptographically generated care-of address, Also included in the signaling packet are the cryptographically generated home address and the public key. Upon receiving the signaling packet, the correspondent node checks that the source address and home address can be generated from the included public key, and then checks the signature. If both the source address and the public keys match expectation, the correspondent node accepts the signaling packet.
RFC 3971, by Jari Arkko, James Kempf, Brian Zill, and Pekka Nikander, March 2005, discloses extending IPv6 Neighbor Discovery Protocol (described in RFC 2461 and 2462) for secure advertising and defending network addresses and for secure discovery of last hop IP routers. A node generates a cryptographically generated address according to an algorithm described in RFC 3972, and signs Neighbor Advertisement packets with an RSA signature. The Neighbor Advertisement packets claim ownership of the address. This claim is proved by the cryptographic property of the address, and the signature on the packet establishes data origin authentication on the packet. Thus, the receiving node can trust that the packet came from the claimed source address, and the message establishes authorization to claim the network address. The SEND protocol additionally allows for secure discovery of last hop routers. In RFC 3972, a format for a certificate on last hop routers is specified. A router possessing such a certificate signs Router Advertisement messages with the private key corresponding to its certified public key. A node seeking a last hop router obtains the router's certificate and a certificate chain leading back to a commonly shared trust root from the router. The node uses the router's certified key to verify the signature on the Router Advertisement, thereby obtaining a certified last hop router.
As can be seen from the above, the Nikander and Schelest Applications, the Montenegro Paper, RFC 3927 and RFC 3971 relate only to cases in which authorization to use the network address is claimed by a single host. Often, however, it may be necessary to authorize one or most hosts to use an address. Some examples can be found in Mobile IPv6 networks and DHCP applications
In a Mobile IPv6 network, a mobile node may be reached using a home address on a home network to which the mobile node is assigned. The home address does not change regardless of where the mobile node is on the Internet. When the mobile node is in a remote subnet outside of its home subnet, a “home agent” (e.g., a router on the mobile node's home subnet) forwards messages addressed to the home address to a “care of” address, which is a local address in the remote subnet. To prevent the home address from claim by another when the mobile node is away from the home network, the home agent must proxy, or defend, the mobile node's home address. However, if the mobile node generates the home address using a cryptographic identifier tied to its public key, only it can securely defend the home address. The proxy defense by the home agent must be done without security.
A similar problem exists for the mobile IPv6 care-of address, when the mobile node is using the Fast Mobile IPv6 (FMIPv6) protocol to optimize handover. During such a handover, the mobile node's old care-of address on the old access router or a new care-of address on the new access router may, for a time, need to be defended, when the mobile node is outside of either subnet. During this time, the mobile node's traffic packets are forwarded between access routers so that the packets are not lost. The access router must proxy the address on behalf of the mobile node, but cannot proxy the address securely using existing techniques.
Under the IPv6 Neighbor Discovery Protocol, even when a host's address is obtained from a Dynamic Host Configuration Protocol (DHCP) server, the host is still required to claim and defend that address on the network. However, such claim and defense cannot be done securely using cryptographically generated addresses because the address is generated by the DHCP server without the host's public key. Nor can the host sign with its private key a message relating to the address, as the host did not generate the address.
While the Arkko Application discloses an owner node delegating advertising and defense of its address to another party, the solution in the Arkko Application is cumbersome. In the Arkko Application, in addition to using both the owner node's and the delegated node's public keys, an attribute certificate is also required. After generating the address, the attribute certificate is sent by the owner node to the delegated node. As described in the Arkko Application, the solution in the Arkko Application identifies whether the claimant is the owner node or the delegated node. This information can be used by an attacker to infer the location or other information about the owner host.